1. Technical Field
The invention relates to communications sessions on data networks.
2. Discussion of the Related Art
This section introduces aspects that may be helpful to facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light. The statements of this section are not to be understood as admissions about either what is in the prior art or what is not in the prior art.
Some data network architectures include separate service and transport planes. The service plane handles control functions related to communications sessions, e.g., control functions related to admission, setup, and termination of communication sessions. The service plane uses one or more special protocols to support control messages for its control functions, e.g., Session-Initiation Protocol (SIP) and Session Description Protocol (SDP). The transport plane handles the routing and delivery of data carrying user packets. The transport plane may use a variety of transport and control protocols, e.g., Real-time Transport Protocol (RTP), Internet Protocol (IP), and User Datagram Protocol (UDP). While the service and transport planes perform different functions, there is often a need to transport control information and data between these two planes. Indeed, the network architecture may include, e.g., one or more other entities that support the transport of such information and data so that requests from the service plane can be performed at the transport plane.
At the service plane, the communications protocol typically enables users connected to edge network nodes to request access to network resources in messages that request and negotiate new communications sessions. The network resources may include port(s) of network node(s), codecs for handling specific media data, policing devices for monitoring communications sessions, and/or marking devices for adjust quality-of-services (QoSs) of data packets. At the service plane, some protocols further enable the users, which are connected to edge nodes, to reserve access to a list of alternate network resources, e.g., alternate codecs for processing of data during the communications session. Such users will then, be able to select a codec from the list as appropriate to process data during the communication session.
One communications protocol with the above-discussed characteristics is SDP. In SDP, message(s) for requests to admit a new communications session and/or message(s) for replying to such requests may include session parameter data similar in form to the following data:
m=audio 3587 RTP/AVP 18 96 2 15 0
a=rtpmap:96 i:LBC/8000
a=sendrecv
The above session parameter data designates that audio data be received on port 3587 via the RTP/AVP protocols and be treated by one of five codecs identified on the SDP message's preference list. The preference list identifies the five codecs as 18, 96, 2, 15, and 0. If the communications session is admitted, a user who is connected to the source or destination node will be able to use any of the five codecs on this list to treat audio data of the communications session at the port 3587. At one time, any one of the codecs on the preference list can be designated to treat such audio data for the communications session, and the codec so designated may be changed during the communications session. The codecs on such a preference list may have different input bandwidth requirements.
At the service plane, messages requesting admission of a new communications session and/or messages replying to such request messages may include requests to support data of other media types. For that reason, SDP messages may include other preference lists. The other preference lists may indicate codec(s) for treating of data of other media types during the communications session.